[SYCL] Add libsycl, a SYCL RT library implementation project #144372

KseniyaTikhomirova · 2025-06-16T15:38:10Z

This patch introduces libsycl, a SYCL runtime library implementation, as a top-level LLVM runtime project.
SYCL spec: https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html

Commit contains the basic folder layout and CMake infrastructure to build a dummy SYCL library.

This is part of the SYCL support upstreaming effort. The relevant RFCs can be found here:

https://discourse.llvm.org/t/rfc-add-full-support-for-the-sycl-programming-model/74080
https://discourse.llvm.org/t/rfc-sycl-runtime-upstreaming/74479

Upcoming PRs:

UR offloading library fetch & build
partial implementation of sycl::platform: requires offloading layer, requires classes for backend loading & enumeration.

This patch introduces libsycl, a SYCL runtime library implementation, as a top-level LLVM runtime project. It contains the basic folder layout and CMake infrastructure to build a dummy SYCL library.

github-actions · 2025-06-16T15:38:28Z

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

KseniyaTikhomirova · 2025-06-16T15:41:33Z

FYI: @tahonermann @dvrogozh @asudarsa @aelovikov-intel

philnik777

Disclaimer: I haven't seen the RFCs related to this before and haven't read through them in detail.

I don't know much about SYCL, but I do know quite a bit about libc++ and why we do things in certain ways there. In case you're interested I'd be happy to talk to you about that. Feel free to contact me on Discord, Discourse or E-Mail if you'd like to set up a meeting.

libsycl/CMakeLists.txt

libsycl/README.md

libsycl/include/sycl/detail/config.hpp

libsycl/CMakeLists.txt

libsycl/include/sycl/detail/config.hpp

philnik777 · 2025-06-16T16:16:59Z

libsycl/src/version.hpp.in

src seems like a weird place for a file that'll be part of the installed headers.

Well, I think that we use this approach to store file that is just an input for generator because of the way we copy headers. Probably a good chance to discuss this approach too.
I noticed that other projects do copy per file instead of doing copy of whole include directory.
I think libcxx uses file list for headers to use copy_if_different tool that copies files only if they were changed. This approach allows to store input files in the same folder with full header files.
copy_directory_if_different is added in later version, in 3.26.
We use copy_directory that doesn't detect changes but works faster. At early stages I believe there is no noticeable difference.
Do you know if there is any other reason for other projects to copy headers per file?

I don't think so, though I wasn't there for that specific part of libc++'s history. Maybe @ldionne knows more.

libsycl/src/platform.cpp

KseniyaTikhomirova

philnik777 thank you for the review, I really appreciate your comments and guidance.

I replied to all your comments and will provide code updates a bit later.

libsycl/CMakeLists.txt

libsycl/.clang-format

libsycl/CMakeLists.txt

libsycl/README.md

libsycl/CMakeLists.txt

libsycl/include/sycl/detail/config.hpp

KseniyaTikhomirova · 2025-06-17T17:10:44Z

libsycl/src/version.hpp.in

Well, I think that we use this approach to store file that is just an input for generator because of the way we copy headers. Probably a good chance to discuss this approach too.
I noticed that other projects do copy per file instead of doing copy of whole include directory.
I think libcxx uses file list for headers to use copy_if_different tool that copies files only if they were changed. This approach allows to store input files in the same folder with full header files.
copy_directory_if_different is added in later version, in 3.26.
We use copy_directory that doesn't detect changes but works faster. At early stages I believe there is no noticeable difference.
Do you know if there is any other reason for other projects to copy headers per file?

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

libsycl/include/sycl/sycl.hpp

libsycl/docs/index.rst

asudarsa

Looks good to me. Couple of minor nits.

Thanks

philnik777 · 2025-06-21T17:53:35Z

Also, it would be great if we could get the precommit CI running ASAP. IIUC the basic configurations would be:

libstdc++/GCC(?)
MSVC STL/MSVC
libunwind/libc++abi/libc++/Clang
That should be pretty lean on the CI resources and could probably easily run in the GH-provided runners for now.

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

libsycl/docs/index.rst

KseniyaTikhomirova · 2025-06-23T15:15:59Z

Also, it would be great if we could get the precommit CI running ASAP. IIUC the basic configurations would be:

libstdc++/GCC(?)

MSVC STL/MSVC

libunwind/libc++abi/libc++/Clang
That should be pretty lean on the CI resources and could probably easily run in the GH-provided runners for now.

Could you please clarify - is it a blocker for the current PR? Can we add it in the following PRs?

philnik777

Also, it would be great if we could get the precommit CI running ASAP. IIUC the basic configurations would be:

libstdc++/GCC(?)

MSVC STL/MSVC

libunwind/libc++abi/libc++/Clang
That should be pretty lean on the CI resources and could probably easily run in the GH-provided runners for now.

Could you please clarify - is it a blocker for the current PR? Can we add it in the following PRs?

I don't think it should be a blocker. I'd like it soon though, since it significantly increases confidence that code changes are correct.

libsycl/include/sycl/__detail/config.hpp

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova · 2025-06-23T16:13:24Z

Also, it would be great if we could get the precommit CI running ASAP. IIUC the basic configurations would be:

libstdc++/GCC(?)

MSVC STL/MSVC

libunwind/libc++abi/libc++/Clang
That should be pretty lean on the CI resources and could probably easily run in the GH-provided runners for now.

Could you please clarify - is it a blocker for the current PR? Can we add it in the following PRs?

I don't think it should be a blocker. I'd like it soon though, since it significantly increases confidence that code changes are correct.

I agree, I will add libsycl build workflow as separate PR.

tahonermann

Thanks @KseniyaTikhomirova! I unresolved one previous comment to follow up some more and added a few other minor comments.

libsycl/src/CMakeLists.txt

libsycl/.clang-format

libsycl/src/CMakeLists.txt

libsycl/CMakeLists.txt

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

asudarsa · 2025-06-27T17:40:29Z

Hi @KseniyaTikhomirova
Can you please take a look at the merge conflict reported here?
Thanks

jhuber6

Should be a fine starting point for now, we can fix things later.

bader · 2025-06-27T17:59:12Z

Hi @KseniyaTikhomirova Can you please take a look at the merge conflict reported here? Thanks

@asudarsa, resolved.

tahonermann

Thank you for responding to my prior comments. I added a number of new comments, many of which are minor. I would really like to see some of the differences between windows and Linux/UNIX build differences eliminated; particularly the library naming differences and the "d" debug postfix naming. The default build should produce binaries named appropriately for a LLVM/Clang monorepo build and distribution (which shouldn't differ much between Windows and Linux/UNIX).

libsycl/.clang-format

libsycl/include/sycl/__detail/config.hpp

libsycl/CMakeLists.txt

libsycl/src/CMakeLists.txt

libsycl/src/ld-version-script.txt

libsycl/src/CMakeLists.txt

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

tahonermann

Thanks @KseniyaTikhomirova, this is looking great. I added a few final comments, but will be very happy to approve once we address these.

tahonermann · 2025-07-10T03:52:15Z

libsycl/CMakeLists.txt

+set(LIBSYCL_ABI_NAMESPACE "V${LIBSYCL_MAJOR_VERSION}" CACHE STRING
+    "The inline ABI namespace used by libsycl. It defaults to Vn where `n` is the current ABI version.")


DPC++ uses _V1 for the inline ABI namespace. libc++ defaults to __1 for the inline ABI namespace and specifically requires that the name be a reserved identifier. See

llvm-project/libcxx/CMakeLists.txt

Lines 204 to 207 in 378e9bb

set(LIBCXX_ABI_NAMESPACE "__${LIBCXX_ABI_VERSION}" CACHE STRING "The inline ABI namespace used by libc++. It defaults to __n where `n` is the current ABI version.")

if (NOT LIBCXX_ABI_NAMESPACE MATCHES "__.*")

message(FATAL_ERROR "LIBCXX_ABI_NAMESPACE must be a reserved identifier, got '${LIBCXX_ABI_NAMESPACE}'.")

endif()

.

I'm inclined to match libc++ here or to at least use a reserved identifier; one that is distinct from what DPC++ uses so that we have a chance of the Clang and DPC++ implementations being able to coexist.

updated in e502190

tahonermann · 2025-07-10T03:58:17Z

libsycl/CMakeLists.txt

+    message( FATAL_ERROR
+      "On Windows libsycl supports compiler which is some version of Microsoft"
+      " Visual C++ or another compiler simulating the Visual C++ cl"
+      " command-line syntax" )


Suggested change

message( FATAL_ERROR

"On Windows libsycl supports compiler which is some version of Microsoft"

" Visual C++ or another compiler simulating the Visual C++ cl"

" command-line syntax" )

message(FATAL_ERROR

"When compiling for Windows, libsycl requires a"

" version of Microsoft Visual C++ or another compiler"

" that uses the Visual C++ cl command-line syntax.")

done in e502190

tahonermann · 2025-07-10T04:11:29Z

libsycl/src/CMakeLists.txt

+
+set(LIB_NAME "sycl")
+set(LIB_OUTPUT_NAME "${LIB_NAME}")
+if (CMAKE_SYSTEM_NAME STREQUAL Windows)


I think we always want to link with one of the DLL variants of the MSVC RT library. How about we do what libc++ does and detect attempted use of a non-DLL variant? See

llvm-project/libcxx/CMakeLists.txt

Lines 387 to 390 in 617af3c

if (LIBCXX_ENABLE_SHARED AND CMAKE_MSVC_RUNTIME_LIBRARY AND

(NOT CMAKE_MSVC_RUNTIME_LIBRARY MATCHES "DLL$"))

message(WARNING "A static CRT linked into a shared libc++ doesn't work correctly.")

endif()

.

Suggested change

if (CMAKE_SYSTEM_NAME STREQUAL Windows)

if (CMAKE_SYSTEM_NAME STREQUAL Windows)

if (NOT CMAKE_MSVC_RUNTIME_LIBRARY MATCHES "DLL$")

message(FATAL_ERROR "libsycl requires a DLL version of the MSVC CRT.")

endif()

check is added in e502190

tahonermann · 2025-07-10T04:15:13Z

libsycl/src/CMakeLists.txt

+set(LIB_NAME "sycl")
+set(LIB_OUTPUT_NAME "${LIB_NAME}")
+if (CMAKE_SYSTEM_NAME STREQUAL Windows)
+  if (CMAKE_BUILD_TYPE STREQUAL Debug OR CMAKE_MSVC_RUNTIME_LIBRARY STREQUAL MultiThreadedDebugDLL)


Do we need to check for "MultiThreadedDebugDLL" specifically? I think the libc++ logic looks appropriate to use here. See

llvm-project/libcxx/CMakeLists.txt

Lines 677 to 679 in 617af3c

if ((NOT CMAKE_MSVC_RUNTIME_LIBRARY AND uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")

OR (CMAKE_MSVC_RUNTIME_LIBRARY MATCHES "Debug"))

set(LIB_SUFFIX "d")

.

Suggested change

if (CMAKE_BUILD_TYPE STREQUAL Debug OR CMAKE_MSVC_RUNTIME_LIBRARY STREQUAL MultiThreadedDebugDLL)

if ((NOT CMAKE_MSVC_RUNTIME_LIBRARY AND uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")

OR (CMAKE_MSVC_RUNTIME_LIBRARY MATCHES "Debug"))

I know we expect CMAKE_MSVC_RUNTIME_LIBRARY to always be set currently, but this logic will still work as expected if we relax that restriction later.

we don't expect it to be always set. We are ok with cmake default value MultiThreaded$<$CONFIG:Debug:Debug>DLL and handle explicitly set values if needed.

MultiThreadedDebugDLL is the only option that is supported for sycl in Debug mode. Why should we introduce confusion by setting "CMAKE_MSVC_RUNTIME_LIBRARY MATCHES "Debug""?

I updated this code but left check of full config name "MultiThreadedDebugDLL".
I know that we do a check for "DLL" match a few lines before. Although I want to keep the full name if it is the only option there.
e502190

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

[SYCL] Add libsycl, a SYCL RT library implementation project (#3)

5bbfeca

This patch introduces libsycl, a SYCL runtime library implementation, as a top-level LLVM runtime project. It contains the basic folder layout and CMake infrastructure to build a dummy SYCL library.

KseniyaTikhomirova requested a review from a team as a code owner June 16, 2025 15:38

llvmbot added the cmake Build system in general and CMake in particular label Jun 16, 2025

philnik777 reviewed Jun 16, 2025

View reviewed changes

KseniyaTikhomirova commented Jun 17, 2025

View reviewed changes

Fznamznon added the SYCL https://registry.khronos.org/SYCL label Jun 18, 2025

KseniyaTikhomirova added 2 commits June 18, 2025 05:59

address comments

fdf4ddb

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

rename detail folder

fb11e68

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova requested review from AlexeySachkov and philnik777 June 18, 2025 14:23

asudarsa requested review from asudarsa and removed request for AlexeySachkov June 18, 2025 15:00

asudarsa reviewed Jun 18, 2025

View reviewed changes

libsycl/include/sycl/sycl.hpp Show resolved Hide resolved

asudarsa reviewed Jun 18, 2025

View reviewed changes

libsycl/docs/index.rst Show resolved Hide resolved

asudarsa approved these changes Jun 18, 2025

View reviewed changes

fix clang format, update docs

e901d30

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

asudarsa reviewed Jun 23, 2025

View reviewed changes

libsycl/docs/index.rst Outdated Show resolved Hide resolved

philnik777 reviewed Jun 23, 2025

View reviewed changes

libsycl/include/sycl/__detail/config.hpp Outdated Show resolved Hide resolved

bader self-requested a review June 23, 2025 15:40

fix more comments

2caf523

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

philnik777 approved these changes Jun 23, 2025

View reviewed changes

tahonermann reviewed Jun 23, 2025

View reviewed changes

libsycl/src/CMakeLists.txt Outdated Show resolved Hide resolved

libsycl/src/CMakeLists.txt Outdated Show resolved Hide resolved

libsycl/src/CMakeLists.txt Show resolved Hide resolved

asudarsa reviewed Jun 23, 2025

View reviewed changes

libsycl/.clang-format Show resolved Hide resolved

jhuber6 reviewed Jun 24, 2025

View reviewed changes

libsycl/src/CMakeLists.txt Outdated Show resolved Hide resolved

libsycl/CMakeLists.txt Show resolved Hide resolved

cmake files update

83458d1

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova requested a review from tahonermann June 24, 2025 14:48

asudarsa requested review from jhuber6 and AlexeySachkov June 27, 2025 17:40

jhuber6 approved these changes Jun 27, 2025

View reviewed changes

Merge branch 'main' into reviewed_addlibsycl

97752d6

tahonermann requested changes Jun 30, 2025

View reviewed changes

KseniyaTikhomirova added 5 commits July 1, 2025 12:42

Merge branch 'llvm:main' into reviewed_addlibsycl

8811e0d

fix cmake related comments

6e47300

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

fix win build

2573733

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

remove version from win library name

554decd

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

Merge branch 'main' into reviewed_addlibsycl

e8e2ca9

KseniyaTikhomirova marked this pull request as draft July 4, 2025 12:33

rest of the changes for version removal

b824da0

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova marked this pull request as ready for review July 4, 2025 15:49

KseniyaTikhomirova requested a review from tahonermann July 4, 2025 15:51

remove extra code for implib name

81c9efd

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

tahonermann requested changes Jul 10, 2025

View reviewed changes

fix comments

e502190

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova requested a review from tahonermann July 10, 2025 12:03

		set(LIBSYCL_ABI_NAMESPACE "V${LIBSYCL_MAJOR_VERSION}" CACHE STRING
		"The inline ABI namespace used by libsycl. It defaults to Vn where `n` is the current ABI version.")

	set(LIBCXX_ABI_NAMESPACE "__${LIBCXX_ABI_VERSION}" CACHE STRING "The inline ABI namespace used by libc++. It defaults to __n where `n` is the current ABI version.")
	if (NOT LIBCXX_ABI_NAMESPACE MATCHES "__.*")
	message(FATAL_ERROR "LIBCXX_ABI_NAMESPACE must be a reserved identifier, got '${LIBCXX_ABI_NAMESPACE}'.")
	endif()

	if (LIBCXX_ENABLE_SHARED AND CMAKE_MSVC_RUNTIME_LIBRARY AND
	(NOT CMAKE_MSVC_RUNTIME_LIBRARY MATCHES "DLL$"))
	message(WARNING "A static CRT linked into a shared libc++ doesn't work correctly.")
	endif()

	if ((NOT CMAKE_MSVC_RUNTIME_LIBRARY AND uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
	OR (CMAKE_MSVC_RUNTIME_LIBRARY MATCHES "Debug"))
	set(LIB_SUFFIX "d")

	if (CMAKE_BUILD_TYPE STREQUAL Debug OR CMAKE_MSVC_RUNTIME_LIBRARY STREQUAL MultiThreadedDebugDLL)
	if ((NOT CMAKE_MSVC_RUNTIME_LIBRARY AND uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
	OR (CMAKE_MSVC_RUNTIME_LIBRARY MATCHES "Debug"))

[SYCL] Add libsycl, a SYCL RT library implementation project #144372

Are you sure you want to change the base?

[SYCL] Add libsycl, a SYCL RT library implementation project #144372

Conversation

KseniyaTikhomirova commented Jun 16, 2025

Uh oh!

github-actions bot commented Jun 16, 2025

Uh oh!

KseniyaTikhomirova commented Jun 16, 2025

Uh oh!

philnik777 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

KseniyaTikhomirova left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

asudarsa left a comment

Choose a reason for hiding this comment

Uh oh!

philnik777 commented Jun 21, 2025

Uh oh!

Uh oh!

KseniyaTikhomirova commented Jun 23, 2025

Uh oh!

philnik777 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

KseniyaTikhomirova commented Jun 23, 2025

Uh oh!

tahonermann left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

asudarsa commented Jun 27, 2025

Uh oh!

jhuber6 left a comment

Choose a reason for hiding this comment

Uh oh!

bader commented Jun 27, 2025

Uh oh!

tahonermann left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

KseniyaTikhomirova Jul 10, 2025 •

edited

Loading